Thanks for the fix — the approach of threading DX props through the plugin layer plumbing is sound and follows the existing pattern.

A few things to consider:

Substantive

1. DX props now go to every plugin — The PluginLayer change passes dxLocation, onDXChange, and dxLocked to all plugin hooks, but only useContestQsos consumes them. Not a bug (unused props are harmless in JS), but worth noting.

2. dxLocation in the useEffect dependency array causes unnecessary re-runs — Every time the DX target moves (map click, spot click, etc.), the auto-target effect re-evaluates even when there are no new QSOs. It bails early via alreadySelected, but the effect really only needs to fire when qsos changes. Consider using a ref for dxLocation instead of including it in deps.

3. [...qsos].reverse().find(...) runs more often than needed — With up to 200 QSOs, this fires every time the effect triggers (which per point 2 is more often than necessary). Moving dxLocation to a ref would tighten this up.

4. The alreadySelected epsilon check is redundant — The targetKey dedup on the line above already prevents duplicate onDXChange writes. The floating-point comparison (1e-6) across different parse paths is fragile and could be removed to simplify.

Unrelated changes

The formatting-only changes to aprs_newsfeed.user.js, N1MM-SETUP.md, and dxspider-proxy/server.js are fine on their own but add noise to a PR titled "Fix contest QSO DX target updates." Consider splitting those into a separate formatting PR to keep this one focused.